A crazy idea?
0 (Zero) Admin Model in your production environment? Personally, I don’t think is crazy. First thing to check when running a security audit, is the number of privileged users. Remember that a privileged user is a member of either Enterprise Admins, Domain Admins or Administrators group. The fact is that more members these groups have, the less secure is our environment. So why not to run our domain without a single user in these groups?
At this moment you must be thinking “how? Admins run many different tasks against Active Directory. No admin means that those tasks will not be complete” … well, this last statement is not true. Active Directory is extremely granular when dealing with delegations.
First things first: a delegation is when a privileged user grants a permission and/or right to an identity. There are some default inherited permissions, like self-password change, just to mention one. Then the idea is to delegate as much as possible, so at the end the administrators or any other built-in group are not needed in our setup. The delegations are those specific things that only an administrator can do.
Privileged users should not be more than 2 (the mighty Administrator, and one additional safeguard account) and Semi-Privileged users should not be more that 2% or 3% of the total users’ objects of the environment. What we are suggesting in this post, is to have all minus one (the built-in Administrator, and additionally a backup administrator) users as Semi-Privileged; this means that all the tasks involving a change to AD must be previously delegated to the different users and/or groups who manage and operate the environment.
Neuron fight result… an idea
To begin with, the Administrator has all possible rights and permissions. From here, there are 2 possibilities:
- Continue using the Administrator benefits (terrible idea!)
- Have the Administrator to delegate specific tasks to separate groups.
Let’s take for example the user management team. They are responsible to create new users objects for onboarding personnel, maintain those objects and decommission accordingly when no longer needed. Of course admins can do this task. And Account Operators can also… well, yes, but as mentioned earlier, admins have to much power just to use them for this purpose; account operators could do the job, but there are 2 small issues to consider:
- This group is a protected group (without going into details, AD manages security of this group and all its members, so any security setting might not work as you wish it would)
- By default, this group can also manage semi-privileged accounts, something that goes against the proposal itself. Only admins should have this right. Even better, a specific purpose delegated group that can only manage the Semi-Privileged accounts.
In this scenario, the Admin will delegate the right to create/manage/delete users on specific container or Organizational Unit. By doing this, we can stop using the Built-In Account Operators group. Even more, we could delegate to 2 separated groups, so one group could manage South users, and the other one could take care for the North ones.
Now that we have a clear idea, lets try to see the big picture. I suggest to start with the most common object classes: User Class, Group Class and Computer Class.
What would I do if I’m working for you
Some months ago, I blog on “Segregation of Duties”, which mainly deals on splitting and separating permissions and rights. To avoid using all the power an Administrator has, we have to create specific-tasks delegations. Is going to be a very challenging process just to remove the users from the Admin group; instead we have to provide the “Least Privileged Access” to the user so she can complete its tasks, and afterwards remove it from the Privileged group.
Certainly, there are some specific tasks that cannot fit into the delegation. Those can be promoting or demoting a Domain Controller, or creating a new domain DFS namespace, to name some. But this does not mean that the user should be part of a Privileged group. A process should be developed and implemented so whoever needs the access, first gets authorization, and then granting temporary rights to perform specific task. This can be accomplish by providing the credentials of the second Admin account (the lifesaver account) and automatically reset the password after predefined elapsed time. Other approach would be to use a PIM solution (Privileged Identity Management).
Our Delegation Model design is flexible enough to accommodate all these technics, increasing the overall security of Active Directory. This is how we end up with a 0 Admin Model.
What we can Achieve by having a 0 Admin Model
By having a 0 Admin model, we avoid exposing Privileged credentials into our environment. This makes more difficult for Pass-the-Hash and Pass-the-Ticket attacks. Although this Technik will not avoid such attacks, it will make more difficult to get such privileged credentials. Is simple, because those credentials are not used, are not getting exposed.
We also reinforce the Delegation Model by having a Least Privileged Access role strategy that also help us to “isolate” the semi-privileged credentials.
We implement a set of technical roles, which will grant specific delegated rights to our semi-privileged users, having a great control over those and enhanced auditing capabilities (maybe not enhanced, but very simple and fast way to know who has right on what).
And last, but not least, a segregation of duties, which is a consequence of the above-mentioned topics.
